From 9f8c12b1cee360ce1dc0d7d8dea45fb446a4167b Mon Sep 17 00:00:00 2001 From: Keir Fraser Date: Wed, 3 Nov 2010 08:18:51 +0000 Subject: [PATCH] VT-d: fix device assignment failure (regression from Xen c/s 19805:2f1fa2215e60) If the device at :00.0 is the device the mapping operation was initiated for, trying to map it a second time will fail, and hence this second mapping attempt must be prevented (as was done prior to said c/s). While at it, simplify the code a little, too. Signed-off-by: Jan Beulich Acked-by: Weidong Han --- xen/drivers/passthrough/vtd/iommu.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/vtd/iommu.c index 6d6ca7f137..4d66a3fcf6 100644 --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1403,23 +1403,16 @@ static int domain_context_mapping(struct domain *domain, u8 bus, u8 devfn) if ( find_upstream_bridge(&bus, &devfn, &secbus) < 1 ) break; - /* PCIe to PCI/PCIx bridge */ - if ( pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE ) - { - ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); - if ( ret ) - return ret; + ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); - /* - * Devices behind PCIe-to-PCI/PCIx bridge may generate - * different requester-id. It may originate from devfn=0 - * on the secondary bus behind the bridge. Map that id - * as well. - */ + /* + * Devices behind PCIe-to-PCI/PCIx bridge may generate different + * requester-id. It may originate from devfn=0 on the secondary bus + * behind the bridge. Map that id as well if we didn't already. + */ + if ( !ret && pdev_type(bus, devfn) == DEV_TYPE_PCIe2PCI_BRIDGE && + (secbus != pdev->bus || pdev->devfn != 0) ) ret = domain_context_mapping_one(domain, drhd->iommu, secbus, 0); - } - else /* Legacy PCI bridge */ - ret = domain_context_mapping_one(domain, drhd->iommu, bus, devfn); break; -- 2.30.2